Type systems for SDN Controllers

Software-defined networking (SDN) offers unprecedented control over network operation, allowing network operators programmatic control over switches’ forwarding behavior. In the compass-rose metaphor for networks, an SDN controller sends commands that modify switches’ forwarding tables (so-called flowmods), queues, counters, etc., by means of the southbound API. Several different southbound APIs exist. OpenFlow [9] is surely the most popular of the SDN APIs, but others exist [1, 5]. SDN replaces old but working legacy distributed algorithms like OSPF with new controller code—which, like all code, will have bugs. Some of these bugs will manifest as bad forwarding behaviors, but others will manifest as southbound protocol errors. As SDN has matured, controllers’ capabilities have expanded— and the southbound APIs have expanded with them. For example, OpenFlow 1.0 specifies that a switch consists of a single match/action table; by OpenFlow 1.1, a switch can have any acyclic topology of tables, and by OpenFlow 1.3 each table can have varying capabilities. Expanding the capabilities of SDN is all to the good, but these new features aren’t free: they introduce new failure modes. OpenFlow 1.0 controllers can only send rules matching a fixed set of headers to a single table, so there are only a few kinds of bad rules that can be sent (e.g., matching on IP fields before checking that the Ethertype is 0x0800 ). In OpenFlow 1.3, there are new kinds of mistakes to be made: sending a rule to the wrong table; sending a match, action, or instruction to a table that doesn’t support it; or sending an instruction to a a table indicating an invalid next table in the Goto-Table instruction.